Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000165_owner-urn-ietf _Thu Nov 14 12:08:10 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA25197 for urn-ietf-out; Thu, 14 Nov 1996 12:08:10 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA25192 for <[e-mail]>; Thu, 14 Nov 1996 12:08:08 -0500
Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA20785  (mail destined for [e-mail]); Thu, 14 Nov 96 12:08:06 -0500
Received: by cs.bu.edu (8.6.10/Spike-2.1)
    id MAA27144; Thu, 14 Nov 1996 12:07:59 -0500
Message-Id: <v02130500aeb0fc2678c3@[128.148.157.46]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 14 Nov 1996 12:13:21 -0500
To: [e-mail]
From: [e-mail] (David G. Durand)
Subject: Re: [URN] Re: I18N does not belong in URNs
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail] (David G. Durand)
Errors-To: [e-mail]

At 5:17 PM 11/13/96, Keith Moore wrote:
>was imprecise and possibly misleading.  A better statement is:
>
>    "URNs aren't intended to serve as human meaningful names".
>
>Keith

This means the human meaningfulness is not a requirement of URNs. This is
probably good. But it is _not_ as you have claimed, a requirement that URNs
_not_ be human-readable.

    As I have repeatedly pointed out, compatibility with existing
persistent namespaces will require that at least some human-meaningful
names be included. The notion of requiring users of FPIs (for instance) to
hex-encode 50+ character ascii strings stil strikes me a ludicrous. But
once we allow ASCII, we have to meet the questions of the international
community. My feeling is that transcribability is a more serious problem
than the UTF-8 advocates are admitting. On the other hand, if the reference
string is the %-encoded UTF-8 value, then we should be OK for
transcribability. The issue of user-friendly software that hides %-encoding
is not part of the protocol, so its _possibility_ shouldn't unduly
influence us.

   We can define the standard as %-encoded UTF-8, and if people implement
this other ways, they are implementing convenience features in the
interface: the software will always have the %-encoded URN available. This
might hurt me in typing in Japanese URNs from a Japanese-language paper
publication, but the scenarios where non-Japanese speakers will be doing
such tasks are pretty contrived.

   I think Martin's argument that if we let in ASCII, we have let the rest
in, has a lot of merit. And I _know_ that one of the best candidates for
initial URN namespace (FPIs) is ASCII-subset based. So we need to find a
harmless way of having a unique, 7-bit clean bytesequence. UTF-8, with
%encoding for characters over 127, is a unique transcribable byte sequence
capable of grandfathering all of the namespaces we have discussed. As long
as we require naming authorities to use well-defined Unicode names, we can
even handle non-Unicode characters, by making authorities that need them
define a policy for their application of the private-use area. consistent
use of private use characters will guarantee uniqueness, so we are all set!

   -- David

_________________________________________
David Durand              [e-mail]  \  [e-mail]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________